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Prozessorarchitektur fur exakte Zeigeridentif izierung 



Technisches Anwendungsgebiet 

Die vorliegende Erfindung betrifft eine Prozessor- 
architektur, bei der der Zugriff auf einen Speicher 
5 uber Zeiger erfolgt, die auf Objekte verweisen. 

Die Beherrschung der Komplexitat von Software ist 
die grofite Herausf orderung bei der Software -Entwick- 
lung. Qualitativ hochwertige und zuverlassige Systeme 

10 sind nur dann realisierbar , wenn es gelingt, Software 
in uberschaubare und beherrschbare Module zu zerlegen 
und abstrakt zu beschreiben. Urn dies zu erreichen, 
werden seit einigen Jahren objektorientierte Program- 
miersprachen eingesetzt. 

15 Ein zentrales Problem bei der Implement ierung 

objektorientierter Programmiersprachen ist die dyna- 
mische Speicherverwaltung . Einige wenige objekt- 
orientierte Sprachen wie z. B. C++ bauen noch auf 
manuelle Speicherverwaltung, d. h. dass Speicher unter 

2 0 der Verantwortung des Programmierers sowohl angefordert 
als auch wieder frei gegeben wird. Dieser Ansatz hat 
jedoch den Nachteil, dass die problemangepasste, 
naturliche Modellierung eines Systems oft nicht moglich 
ist, da beim Entwurf des Systems auch die Speicher- 

25 verwaltung realisiert werden muss. Weiterhin ist die 
manuelle Freigabe von Speicher Ursache einer ganzen 
Klasse von Programmf ehlern. Wird bspw. ein Speicher- 
bereich freigegeben, obwohl noch Verweise auf diesen 
Speicherbereich existieren, kann dies im weiteren 

30 Programmablauf katastrophale Folgen nach sich Ziehen. 
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Besonders gravierend ist hierbei, dass die Folgen der 
durch die noch existenten Zeiger auf den bereits frei 
gegebenen Speicherbereich (sog. dangling references) 
verursachten Fehler von vielen Faktoren abhangen und 
5 deshalb kaum zu reproduzieren und nur schwer zu loka- 
lisieren sind. Aus diesen Grunden bauen fast alle 
modernen Programmiersprachen, wie bspw. Java, auf 
dynamische Speicherverwaltung mit automat ischer 
Speicherbereinigung (sog. garbage collection) . In 

10 Systemen mit dieser dynamischen Speicherverwaltung 

konnen Speicherbereiche nicht unter Verantwortung des 
Programme zuruck gegeben werden. Statt dessen gibt ein 
Speicherbereiniger (garbage collector) die Speicher- 
bereiche automatisch erst dann frei, wenn sie von einem 

15 Programm sicher nicht mehr referenziert werden. Dadurch 
konnen prinzipbedingt keine "dangling references" 
auftreten. Weiterhin erhoht der Einsatz dieser Technik 
die Produktivitat der Programmierer , da diese sich nun 
vollstandig der Losung des eigentlichen Problems widmen 

20 konnen. SchlieSlich ist die erstellte Software von 

hoherer Qualitat, da die Wahrscheinlichkeit versteckter 
Programmf ehler in einem System mit dynamischer Spei- 
cherverwaltung deutlich geringer ist als in einem 
System mit manueller Speicherverwaltung. 



Stand der Technik 

Fur die automatische Freigabe dynamisch angelegter 
30 Speicherbereiche existieren zahlreiche Algorithmen, die 
dem Fachmann unter den Begriffen Reference Counting, 
Copying und Mark Sweep Collection bekannt sind. Fur 
einen Uberblick uber diese Algorithmen wird auf R. 
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Jones, R. Lins : „ Garbage Collection: Algorithms for 
Automatic Dynamic Memory Management u , John Wiley & 
Sons, 1996 , verwiesen. 

5 Einfache Implementierungen dieser Algorithmen 

unterbrechen das Anwendungsprogrammm fur die gesamte 
Dauer eines Speicherbereinigungszyklus . Sie verursachen 
in der Regel lange und unvorhersehbare Pausen in der 
Programmausfiihrung und sind deshalb nicht fur inter- 

10 aktive Systeme oder Echtzeitumgebungen geeignet. 

Inkrementelle und nebenlaufige Verfahren erlauben 
es, die Programmausfiihrung wahrend eines Speicherberei- 
nigungszyklus f ortzusetzen. Sie erfordern allerdings 
die Synchronisation zwischen Anwendungsprogramm und 

15 Speicherbereiniger . Die Kosten dieser Synchronisation 
in Software sind jedoch erheblich, da, je nach verwen- 
detem Verfahren, entweder vor jedem Laden eines Zeigers 
(read barrier) oder vor jedem Speichern eines Zeigers 
(write barrier) eine kurze Codesequenz eingefugt werden 

2 0 muss, urn f est zustellen, ob das zugehorige Objekt vom 
Speicherbereiniger bereits bearbeitet wurde. 

Viele inkrementelle Verfahren werden als „echt- 
zeitfahig" beschrieben, weil die vom Speicherbereiniger 
verursachten Pausen in den meisten Fallen zu kurz sind, 

2 5 um vom Anwender registriert zu werden. Harte Echtzeit- 

fahigkeit erfordert jedoch die Garantie einer konstan- 
ten oberen Schranke fur die Antwortzeit eines Systems. 
Da software -basierte Verfahren in der Regel auf nicht 
unterbrechbare Operationen wie die Untersuchung aller 

3 0 Zeiger der Wurzelmenge (Register und Stapel) oder die 

Bearbeitung eines vollstandigen Objekts angewiesen 
sind, genugen sie harten Echtzeitanf orderungen nicht. 
Es sind zwar Sof tware-Losungen bekannt , die ohne ato- 
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mare Operationen unbeschrankter Dauer auskommen, jedoch 
ist der Overhead dieser Losungen an Rechenzeit und 
Speicher erheblich. 

5 Ein grundsatzliches Problem aller Techniken zur 

automat ischen Speicherbereinigung besteht im Auf finden 
und Identif izieren von Zeigern. Wenn Zeiger nicht ein- 
deutig von Nicht -Zeigern unterschieden werden konnen, 
so lasst sich lediglich eine konservative Speicher- 

10 bereinigung durchfiihren. Dies bedeutet, dass jedes 

Bitmuster, das einen Zeiger darstellen konnte, auch als 
Zeiger betrachtet werden muss, um die Freigabe von noch 
in Benutzung befindlichem Speicher zu vermeiden. Bei 
einer konservativen Speicherbereinigung durfen daher 

15 keine kompaktierenden Verfahren eingesetzt werden, die 
Objekte verschieben und Zeiger aktualisieren. Ohne kom- 
paktierende Verfahren wird der Speicher jedoch fragmen- 
tiert . 

Zur Vermeidung dieser Problematik und zur Durch- 
2 0 fuhrung einer exakten Speicherbereinigung wird ein 

grofier Auf wand bei der Suche und Identif izierung von 
Zeigern betrieben. Bei vielen objektorientierten Spra- 
chen konnen Zeiger in Objekten uber Typbeschreibungen 
(type descriptors) identif iziert werden, die in jedem 
25 Objekt enthalten sind. Die Lokalisierung von Zeigern im 
Programmstapel sowie in den Prozessorregistern ist 
jedoch schwieriger, insbesondere im Zusammenhang mit 
optimierenden Compilern. Es ist zwar moglich, Daten- 
strukturen zu unterhalten, in denen die Stapelpositio- 
30 nen und die Prozessorregister angegeben sind, die 

momentan Zeiger enthalten, jedoch sind die Kosten zur 
Aktualisierung derartiger Datenstrukturen wahrend der 
Programmaus fuhrung sehr hoch. Aus diesem Grund ver- 
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wenden die meisten sof tware-basierten Verfahren vom 
Compiler erzeugte Tabellen, die die Lage der Zeiger im 
Programmstapel sowie in den Registern beschreiben. Fur 
jeden Programmpunkt , an dem eine Speicherbereinigung 
5 durchgefuhrt werden konnte, wird ein Satz derartiger 
Tabellen erstellt. Die Realisierung dieser Technik 
fiihrt jedoch zu einem bet racht lichen Aufblahen des 
Programmcodes . Weiterhin miissen Echtzeitsysteme sicher 
stellen, dass zu suspendierende Threads den nachsten 
10 derartigen Programmpunkt innerhalb einer begrenzten 
Zeitspanne erreichen. 

Mit den bisher bestehenden Systemen, die in erster 
Linie auf eine automatische Speicherbereinigung in 

15 Software setzen, mussen somit zahlreiche Probleme 

bewaltigt werden. Dies beruht vor allem darauf, dass 
die Software Funktionen nachbilden muss, die die 
zugrunde liegende Hardware nicht zur Verfugung stellt. 
Viele Probleme hinsichtlich Effizienz und Echtzeit- 

20 fahigkeit konnen behoben werden, wenn der Prozessor 

selbst die automatische Speicherbereinigung ganz oder 
teilweise in Hardware durchf uhrt . Dafiir ist es jedoch 
zwingend erf orderlich, dass der Prozessor Zeiger iden- 
tifizieren kann. 

25 

Im Folgenden werden von den zahlreichen bekannten 
Architekturen lediglich zwei beispielhaft angefuhrt, 
die eine exakte Zeigeridentif izierung und/oder automa- 
tische Speicherbereinigung unterstutzen und fur den 
3 0 Gegenstand der vorliegenden Erfindung von Bedeutung 
sind. 
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So sind seit 1966 Architekturen bekannt, die sog. 
Capabilities an Stelle von direkten Zeigern einsetzen, 
urn Speicherbereiche zu adressieren. Capabilities ent- 
halten Angaben zur Zugangsberechtigung und Identifizie- 
5 rung von Objekten. Sie enthalten nicht die physikali- 
sche Adresse des Objekts, sondern einen Verweis auf 
einen Deskriptor, der den Ort, die GroSe sowie weitere 
Eigenschaf ten des Objekts beschreibt. Ein Beispiel fur 
einen Prozessor mit einer derartigen Architektur ist 

10 der Intel iAPX 432, wie er bspw. in H. M. Levy: 

„ Capability-Based Computer Systems u , Digital Press, 
1984, Seiten 159 - 186, beschrieben ist. In dieser 
Architektur wird eine Capabilitiy durch einen zweistu- 
figen Abbildungsprozess mit dem zugehorigen Objekt 

15 assoziiert. Fur jedes Objekt existiert ein eindeutiger 
Eintrag in einer Objekttabelle, der den Ort, die Grofie 
und den Zustand des Objekts beschreibt. Jedes Objekt 
besteht aus zwei Bereichen: Einem Datenbereich und 
einem Bereich fur Capabilities. Auf diese Weise wird 

20 eine exakte Capability- Identif izierung ermoglicht. 

Durch das Fehlen eines Registersatzes und die 
doppelt indirekte Adressierung eines Objekts uber 
Capabilities und Objektdeskriptoren ist der iAPX 432 
auSerst ineffizient. Weiterhin fuhrt er selbst keine 

25 automatische Speicherbereinigung durch. Die Speicher- 
bereinigung muss in Software erfolgen und ist nicht 
echtzeitf ahig. 

Alle bekannten Verfahren zur Identif izierung von 
3 0 direkten Zeigern verwenden in jedem Speicherwort ein 
spezielles Kennzeichnungsbit (tag) zur Unterscheidung 
von Zeigern und Nicht -Zeigern. Ein Beispiel dafiir ist 
das in der US 5,560,003 A beschriebene System und Hard- 
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ware-Modul fur inkrementelle Speicherbereinigung in 
Echtzeit, das sich aus zwei Speicherbanken und einem 
Lokalprozessor zusammensetzt, der die Speicherbereini- 
gung durchfuhrt. Jede Speicherbank wird von einem sog. 
5 Ob jektraum- Manager unterstutzt, der bei jedem Speicher- 
zugriff die Startadresse des entsprechenden Objekts 
ermittelt. Aufgrund seiner Komplexitat muss dieser 
Objektraum-Manager als getrenntes ASIC realisiert 
werden, das eine ahnliche Chipflache beansprucht wie 
10 der Speicher selbst . Ein derartiges System ist sehr 

kostspielig. Weiterhin verursacht die Identif izierung 
von Zeigern mit Hilfe von Kennzeichnungsbits zusatz- 
lichen Aufwand in Form von Rechenzeit und Speicherbe- 
darf . 

15 

Wegen der standig steigenden Komplexitat der Soft- 
ware in eingebetteten Systemen werden seit einigen 
Jahren groSe Anstrengungen unternommen, die Vorteile 
der automat ischen Speicherbereinigung auch diesem wirt- 

20 schaftlich wichtigen Bereich zuganglich zu machen. 

Gerade in diesem Bereich der modernen Inf ormationstech- 
nik werden die groSten Stiickzahlen erzielt. Da die 
Produktzyklen durch standige Innovation immer kurzer 
werden, steigt die Nachfrage nach robusten und echt- 

25 zeitfahigen Plattformen fur eingebettete Systeme fur 

moderne obj ektorientierte Sprachen standig. Allerdings 
wird die automatische Speicherbereinigung fur diese 
Anwendungen in den meisten Fallen noch immer als ein 
Luxus betrachtet, den man sich trotz der unumstrittenen 

30 Vorteile der automatischen Speicherbereinigung nicht 
leisten kann. 
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Ausgehend von diesem Stand der Technik besteht die 
Aufgabe der vorliegenden Erfindung darin, eine Prozes- 
sorarchitektur fur objektbasierte und objektorientierte 
Programme anzugeben, die eine kostengunstige exakte 
5 Zeigeridentif izierung ermoglicht und somit den Weg fur 
eine effiziente und echtzeitf ahige automatische 
Speicherbereinigung freigibt, die ganz oder teilweise 
in Hardware realisiert werden kann. 

10 Darstellung der Erfindung 

Die Aufgabe wird mit der Prozessorarchitektur 
gemaS Patentanspruch 1 gelost. Vorteilhafte Ausge- 
staltungen der Prozessorarchitektur sind Gegenstand der 
Unteranspruche oder lassen sich aus der nachf olgenden 
15 Beschreibung sowie den Ausf uhrungsbeispielen entnehmen. 

Im Rahmen der vorliegenden Patentanmeldung wird 
der Begriff Wort als Dateneinheit verstanden, die 
mittels einer einzigen Prozessoranweisung aus dem Spei- 

2 0 cher geladen oder im Speicher abgelegt werden kann. 

Unter einem Objekt wird eine zusammenhangende Menge an 
Speicherworten verstanden, in der jedes Wort exklusiv 
einem einzelnen Objekt angehort . Unter einem Zeiger 
wird ein Wort verstanden, das auf ein Objekt verweist. 

25 Der Begriff Null reprasentiert einen fest vorgegebenen 
Zeigerwert, der benutzt wird, urn auf kein Objekt zu 
verweisen . 

Bei der vorliegenden Prozessorarchitektur fur 
30 objektbasierte und objektorientierte Programme erfolgt 
der Zugriff auf den Speicher ausschlieSlich uber 
Zeiger, die direkt auf Objekte verweisen. Ein Objekt 
wird in einem zusammenhangenden Speicherbereich exklu- 
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siv abgelegt, d. h. die von zwei Objekten belegten 
Speicherbereiche durfen sich nicht uberlappen. In jedem 
Objekt werden Zeiger in einem Zeigerbereich und Daten 
in einem Datenbereich getrennt voneinander abgelegt. 
5 Dariiber hinaus werden in jedem Objekt Inf ormationen 
uber die Lange des Zeigerbereichs und die Lange des 
Datenbereichs abgelegt. Diese Langeninf ormationen 
werden nachfolgend als Attribute bezeichnet. Mit Hilfe 
der Attribute ist es jederzeit moglich, die GroSe eines 

10 Objekts zu bestimmen und die Zeiger und Daten in einem 
Objekt eindeutig voneinander abzugrenzen. 

Die vorliegende Prozessorarchitektur stellt 
getrennte Zeigerregister- und Datenregistersatze zur 
Verfugung. Dabei sind Zeigerregister ausschlieSlich fur 

15 Operationen mit Objekten wie bspw. fur Speicherzugrif f e 
vorgesehen und werden nicht fur andere Aufgaben verwen- 
det. Dadurch wird insbesondere sichergestellt , dass 
keine beliebigen Werte in Zeigerregister geschrieben 
werden und keine arithmetischen Operationen mit Zeiger- 

2 0 registern durchgefiihrt werden konnen. 

Die Zeiger in den Zeigerbereichen der Objekte und 
in den Zeigerregistern enthalten direkt die Adresse der 
Objekte im Speicher. 

2 5 Mit der vorliegenden objektbasierten Prozessor- 

architektur wird auf diese Weise eine strikte Trennung 
von Zeigern und Nicht -Zeigern (Daten) realisiert, 
sodass eine exakte Zeigeridentif izierung ohne die Not- 
wendigkeit von Kennzeichnungsbits moglich ist. Durch 

3 0 diese von der Hardware sicher gestellte exakte Identi- 

f izierbarkeit der Zeiger in den Prozessorregistern und 
im Speicher lasst sich eine automat ische Speicherberei- 
nigung auf Prozessorebene integrieren, die ganz oder 



WO 2005/003960 



PCTYEP2004/007175 



- 10 - 

teilweise in Hardware implement iert werden kann. Auf 
dieser Grundlage werden echtzeitf ahige Systeme mit 
automat ischer Speicherbereinigung moglich, die beson- 
ders effizient implement iert werden. konnen. So ist 
5 weder fur den Speicherbereinigungsalgorithmus selbst 
noch fur die erf orderliche Synchronisation zwischen 
Prozessor und Speicherbereiniger Software erf orderlich, 
die auf dem Prozessor ausgefuhrt werden muss. Der Pro- 
zessor muss lediglich einen Teil der Speicherbandbreite 

10 an den Speicherbereiniger abtreten. 

Ein weiterer Vorteil der Architektur besteht 
darin, dass die Speicherbereinigung ohne die Koope- 
ration des Compilers und/oder des Lauf zeitsystems 
auskommt und deshalb besonders robust implementiert 

15 werden kann. 

Der Hardware -Auf wand fur die Realisierung der 
Speicherbereinigung ist gemessen am Aufwand fur den 
Prozessor selbst vergleichsweise gering. Aus diesem 
Grund konnen solche Prozessoren genauso wirtschaf tlich 

2 0 wie herkommliche Mikroprozessoren oder Mikrocont roller 

hergestellt werden. 

Vorzugsweise wird bei der vorliegenden Prozessor- 
architektur durch den Prozessor gewahrleistet , dass 
25 jedes als Zeiger identif izierte Wort entweder die 

Adresse eines existierenden Objekts beinhaltet oder 
Null ist. Bei dieser bevorzugten Ausgestaltung wird 
durch die Prozessorarchitektur somit die feste Regel 
(Systeminvariante) eingehalten, dass einerseits jedes 

3 0 Speicherwort oder Register dahingehend identif iziert 

werden kann, ob es ein Zeiger ist oder nicht, und 
andererseits jeder Zeigerwert entweder Null ist oder 
die Adresse eines existierenden Objekts enthalt. Durch 
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das Einhalten dieser Systeminvariante wird die exakte 
Identif izierung der Zeiger im System zu jedem Taktzeit- 
punkt ermoglicht. 

Vorzugsweise werden neue Objekte durch einen 
speziellen Objekterzeugungsbef ehl angelegt, dem die 
Attribute des anzulegenden Objekts als Parameter 
ubergeben werden. Dieser Objekterzeugungsbef ehl initia- 
lisiert alle Zeiger des Zeigerbereichs mit dem Null- 
Wert, bevor auf das Objekt zugegriffen werden kann. Auf 
diese Weise wird die Systeminvariante nicht verletzt. 

In einer Weiterbildung fur harte Echtzeitanf orde- 
rungen wird der Objekterzeugungsbef ehl unterbrechbar 
implementiert , wobei beim Abbruch eines Objekterzeu- 
gungsbefehls unvollstandig initialisierte Objekte 
derart erzeugt werden, dass der unterbrochene Objekter- 
zeugungsbef ehl zu einem spateren Zeitpunkt fortgesetzt 
werden kann und dass unvollstandig initialisierte 
Objekte vom Prozessor in eindeutiger Weise gekennzeich- 
net werden. 

Vorzugsweise werden von der Prozessorarchitektur 
konstante Objekte unterstutzt, die bereits vor dem 
Programmstart als Teil eines nur lesbaren Speicherbe- 
25 reiches existieren. Zeiger auf konstante Objekte werden 
vom Prozessor in eindeutiger Weise gekennzeichnet . 

Vorzugsweise wird bei der vorliegenden Prozessor- 
architektur in bekannter Weise ein Bereich des Spei- 
30 chers fur einen Programmstapel reserviert. Der Pro- 

grammstapel wird hierbei in einen Zeigerstapelbereich 
und einen Datenstapelbereich unterteilt, wobei jeweils 
die erste nicht vom Stapel belegte Position durch einen 
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Stapelindex angegeben wird, der in je einem reservier- 
ten Datenregister verwaltet wird. 

Werden mehrere Stapel verwendet, so werden die 
Stapelindizes der momentan inaktiven Stapel vorzugs- 
5 weise als Attribute in den zugehorigen Stapelobj ekten 
abgelegt. Weiterhin werden die Stapelobj ekte als sog. 
statische Objekte vorzugsweise nicht im Heap, sondern 
in einem vom Betriebssystem verwalteten statischen 
Speicherbereich abgelegt und Zeiger auf derartige 
10 Objekte (statische Zeiger) in besonderer Weise gekenn- 
zeichnet - 

Zur effizienten Implementierung der Prozessorar- 
chitektur wird jedes Zeigerregister vorzugsweise von 
einem Attributregister begleitet, in dem die Attribute 
des Objekts abgelegt werden, die zu dem mit dem Zeiger 
im Zeigerregister ref erenzierten Objekt gehoren. Bei 
dieser Ausgestaltung ist eine zusatzliche Pipeline- 
Stufe zum Laden der Attribute vorgesehen, Weiterhin 
wird in dieser Pipeline-Stuf e vorzugsweise ein Attri- 
but-Cache zur Beschleunigung der Zugriffe eingesetzt. 

Alle weiteren fur die Programmausf uhrung erforder- 
lichen Pipeline-Stuf en und Funktionseinheiten sowie die 
ublichen Optimierungen wie bspw. Instruktions- und 
Daten-Caches Oder Einheiten zur Sprungvorhersage konnen 
bei einer Implementierung der vorliegenden Prozessorar- 
chitektur gemaS des Standes der Technik realisiert 
werden . 

30 Kurze Beschreibung der Zeichnungen 

Die erf indungsgemaSe Prozessorarchitektur wird 
nachfolgend anhand eines Ausf uhrungsbei spiels in Ver- 
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bindung mit den Zeichnungen eingehend erlautert . 
Hierbei zeigen: 

Fig. 1 schematisch das Registermodell der 

5 vorliegenden Prozessorarchitektur; 

Fig. 2 schematisch das Objektmodell der 

vorliegenden Prozessorarchitektur; 

Fig. 3 schematisch die Realisierung des 

Programmstapels als Stapelobjekt ; 

10 Fig. 4 eine Tabelle mit einer Klassifi- 

kation der zeigerbezogenen Befehle; 

Fig. 5 ein Beispiel fur die Realisierung 

des Objekt layouts fur die vorlie- 
genden Prozessorarchitektur; 

15 Fig. 6 schematisch ein Zeigerregister mit 

Attributen; 

Fig. 7 ein Beispiel fur die Realisierung 

einer Pipeline fur die vorliegende 
Prozessorarchitektur (vereinf achte 
20 Darstellung) ; 

Fig. 8 die Zerlegung zeigerbezogener Be- 

fehle auf die Stufen einer Pipeline 
gemaS Figur 7; und 

Fig. 9 eine schematische Darstellung eines 

25 Beispiels der vorliegenden 

Vorrichtung . 



Wege zur Ausfuhrung der Erf indung 

Im Folgenden wird ein Beispiel fur eine Ausgestal- 
30 tung der erf indungsgemaSen Prozessorarchitektur be- 
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schrieben, die vor allem auf der Zielsetzung basiert, 
eine exakte Zeigeridentif izierung ohne die Verwendung 
von Kennzeichnungsbits (tags) zu erreichen, einen 
allgemein verwendbaren RISC-Bef ehlsatz zu Grunde zu 
5 legen, der effizient implementiert werden kann, sowie 
keine unteilbaren Operationen vorauszusetzen, deren 
Ausfuhrungszeit einige Taktzyklen ubersteigt. 

Die dargestellte Prozessorarchitektur garantiert 
10 die Systeminvariante, dass 

1. jedes Speicherwort oder Register dahingehend 
identif iziert werden kann, ob es einen Zeiger dar- 
stellt oder nicht, und 

2. jeder Zeigerwert entweder Null ist oder eindeu- 
15 tig einem existierenden Objekt zugeordnet ist. 

Die vorliegende Prozessorarchitektur stellt ge- 
trennte Daten- und Zeigerregistersatze bereit, wie dies 
in Figur 1 schematisch verdeutlicht wird. Die im rech- 

20 ten Teil dargestellten Datenregister werden als Mehr- 
zweckregister eingesetzt, wahrend die im linken Teil 
dargestellten Zeigerregister fur den Zugriff auf Objek- 
te im Speicher genutzt werden. N p gibt hierbei die An- 
zahl der Zeigerregister, Na die Anzahl der Datenregi- 

25 ster an. Urn der Systeminvariante zu genugen, muss 
sichergestellt werden, dass es nicht moglich ist, 
beliebige Werte in Zeigerregister zu schreiben, wie 
bspw. den Wert eines Datenregisters in ein Zeigerre- 
gister zu kopieren oder arithmetische Operationen mit 

3 0 Zeigerregistern durchzuf uhren . 
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Das Speichermodell der vorliegenden Prozessor- 
architektur ist objektbasiert . Jedes Objekt setzt sich 
aus einem Datenbereich und einem Zeigerbereich zusam- 
men, die streng voneinander getrennt sind. Figur 2 
5 zeigt den schematischen Aufbau eines derartigen Objekt s 
mit den entsprechenden Zeigerworten im Zeigerbereich 
(linker Teil der Figur) und den Datenworten im 
Datenbereich (rechter Teil der Figur) des Objekts. Die 
Anzahl der Datenworte im Datenbereich wird mit dem 8- 

10 Attribut (5 2 0) , die Anzahl der Zeiger im Zeigerbe- 
reich mit dem n-Attribut (it s 0) beschrieben. Die durch 
die Attribute beschriebene GroSe eines Objekts wird 
festgelegt, wenn das Objekt erzeugt wird und kann 
spater nicht mehr geandert werden. Die Attribute sind 

15 Teil des Objekts und werden in diesem in einem geson- 
derten Attributbereich abgelegt. 

Der fur die vorliegende Prozessorarchitektur 
spezifische Teil des Bef ehlssatzes umfasst lediglich 

20 zeigerbezogene Befehle einschlieSlich Lade- und Spei- 
cherbefehle. Die Ausgestaltung anderer Befehle, wie 
bspw. arithmetischer Befehle oder von Befehlen zur 
Programmsteuerung kann unabhangig von der beschriebenen 
Architektur gewahlt werden und ist nicht Teil der vor- 

25 liegenden Erfindung. 

Der Befehlssatz der beschriebenen Architektur 
weist einen speziellen Obj ekterzeugungsbef ehl auf, der 
zur Erzeugung eines neuen Objekts und eines Zeigers auf 
3 0 dieses Objekt dient. Der Obj ekterzeugungsbef ehl 

(Allocate Object) erhalt die Werte des 71- und 8-Attri- 
buts fur das zu erzeugende Objekt als Argumente und 
legt den Zeiger auf das neu erzeugte Objekt in einem 
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Zeigerregister ab. Jedes Zeigerwort im Zeigerbereich 
des erzeugten Objekts wird mit Null initialisiert , 
bevor der Zeiger auf das Objekt fur das Programm sicht- 
bar wird. Es gibt keinen Befehl zum Loschen eines 
5 Objekts. Objekte konnen nur durch eine automat ische 

Speicherbereinigung auf Prozessorebene geloscht werden. 

Lade- und Speicherbef ehle werden fur den Zugriff 
auf Worte innerhalb eines Objekts eingesetzt. Die Pro- 

10 zessorarchitektur stellt fur den Zugriff auf Zeiger- 
worte und Datenworte unterschiedliche Lade- und Spei- 
cherbef ehle zur Verfugung. Die „Lade Datum"- und 
„Speichere Datum" -Bef ehle bewegen Datenworte aus- 
schliefilich zwischen Datenbereichen von Objekt en und 

15 Datenregistern. Die „Lade Zeiger" - und „Speichere 

Zeiger" -Bef ehle bewegen Zeiger ausschlieSlich zwischen 
Zeigerbereichen von Objekten und Zeigerregistern. Die 
Lade- und Speicherbef ehle identif izieren das Speicher- 
wort, auf das zugegriffen werden soil, mit Hilfe eines 

20 Zeigerregisters, das den Zeiger auf das Objekt enthalt, 
und mit Hilfe eines ganzzahligen, posit iven Index. Zur 
Berechnung der Indexwerte konnen - in Analogie zu den 
Adressierungsarten konventioneller Architekturen - ver- 
schiedene „Indizierungsarten w verwendet werden, die 

25 bspw. Datenregister, konstante Offsets und Skalierungs- 
faktoren verkniipfen. 

Beim Zugriff auf ein Objekt mussen Bereichsiiber- 
prufungen durchgefuhrt werden, um sicherzustellen, dass 
keine Zugriff e auf Worte auSerhalb des jeweils referen- 

3 0 zierten Objekts moglich sind. Solche Zugriff e konnen 

katastrophale Folgen nach sich Ziehen und die Systemin- 
variante verletzen. Aus diesem Grund wird im Falle 
einer Bereichsuberschreitung der Speicherzugrif f abge- 
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brochen und eine entsprechende Ausnahmebehandlung ein- 
geleitet. Aus ahnlichen Grunden werden Befehle abgebro- 
chen, die versuchen, einen Null-Zeiger zu deref erenzie- 
ren. 

5 

Die Attribute eines Objekts konnen durch zwei 
„Lese Attribute * -Befehle abgefragt werden. 

Im Gegensatz zu der Vielzahl von „ Register- zu- 
10 Register u -Bef ehlen, die in der Regel fur Operationen 

auf Datenregister implementiert werden, wird durch die 
vorliegende Architektur ein stark beschrankter Satz von 
zwei Befehlen fur zeigerbezogene „ Register- zu- 
Register w -Bef ehle definiert. Der „Kopiere Zeiger"- 
15 Befehl kopiert den Inhalt eines Zeigerregisters in ein 
anderes Zeigerregister , wahrend der „Vergleiche 
Zeiger M -Befehl uberpruft, ob zwei Zeiger auf dasselbe 
Objekt verweisen. 

20 Figur 4 zeigt eine Zusammenf assung der von der 

vorliegenden Prozessorarchitektur definierten zeiger- 
bezogenen Befehle und kategorisiert sie danach # ob sie 
Zeigerregister lesen, schreiben oder deref erenzieren. 
Das Register, das jeweils gelesen, geschrieben oder 

25 deref erenziert wird, ist fett gedruckt . 

Aufgrund der unstrukturierten und hochdynamischen 
Natur von Programmstapeln stellen diese eine der 
groSten Herausf orderungen hinsichtlich der Zeigeriden- 
30 tifizierung im Rahmen einer automatischen Speicherbe- 
reinigung dar. Bei der vorliegenden Prozessorarchitek- 
tur wird der Programmstapel als Stapelobjekt angesehen, 
das - wie jedes Objekt - einen Datenbereich und einen 
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Zeigerbereich aufweist und damit als zwei getrennte 
Stapel angesehen werden kann. Ein Zeigerregister wird 
reserviert, urn den Zeiger auf das Stapelobjekt zu 
halten. In jedem der beiden Stapelbereiche wird ein 
5 Stapelindex eingesetzt, urn den entsprechenden Bereich 
in den tatsachlichen Stapel und einen momentan unbeleg- 
ten Bereich einzuteilen. Der Stapelindex bezieht sich 
im vorliegenden Beispiel auf die erste unbelegte Spei- 
cherstelle. Ein Stapelindex von 0 reprasentiert einen 
10 leeren Stapel. Die beiden Stapelindizes werden als 
Da t ens t ape 1 index (dsix) und Zeigerstapel index (psix) 
bezeichnet. Jeder dieser Indizes wird in einem speziell 
dafur reservierten Datenregister gehalten. 

Wenn das Stapelobjekt wie ein gewohnliches Objekt 
15 behandelt wird, so kann das System nicht unterscheiden, 
ob ein Zeiger zum aktuell belegten Zeigerstapel oder 
zutn unbelegten Teil des Zeigerstapelbereiches gehort. 
Da jedes Wort im Zeigerstapelbereich als Zeiger identi- 
fiziert wird, kann der ungenutzte Bereich des Zeiger- 
20 stapelbereichs viele Zeiger enthalten, die auf nicht 
mehr benotigte Objekte zeigen. Ein Speicherbereiniger 
(garbage collector) konnte diese Objekte nicht frei 
geben, da noch Zeiger auf diese Objekte vorhanden sind. 
Eine mogliche Losung dieses Problems besteht darin, je- 
25 den Zeigerwert mit Null zu uberschreiben, sobald der 
entsprechende Zeiger vom Stapel entfernt wird. Dies 
fuhrt jedoch zu einem unerwunschten Overhead, insbeson- 
dere dann, wenn mehrere Zeiger vom Stapel entfernt 
werden sollen, wie das bspw. beim Abbau eines Stapel - 
30 rahmens am Ende eines Unterprogramms der Fall ist. 

Fur das hier beschriebene Beispiel einer vorteil- 
haften Ausgestaltung der Prozessorarchitektur wird 
daher eine Losung gewahlt, die die dynamische GroSe 
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eines Stapels beriicksichtigt . Hierbei wird das Stapel- 
objekt, wie in Figur 3 veranschaulicht , durch zwei 
Attributpaare beschrieben, von denen ein Paar (n, 8) 
die aktuelle Stapelgrofie und ein zweites Paar (II, A) 
5 die maximale StapelgroSe angibt. Das 7i-Attribut ent- 
spricht dabei dem Wert des Zeigerstapel index psix, das 
8-Attribut dem Wert des Datenstapel index dsix. Die 
Stapelattribute n und A werden in Systemregistern 
gehalten, die fur Anwenderprogramme nicht sichtbar 

10 sind. Hinsichtlich der Zeigeridentif izierung und der 
Systeminvariante werden lediglich Zeiger mit Indizes 
kleiner als n als Zeiger angesehen. 

Speicherworte innerhalb des Stapels werden durch 
gewohnliche Lade- und Speicherbef ehle angesprochen . 

15 Worte konnen vom Stapel entfernt werden, indem der Wert 
des entsprechenden Stapelindex mittels gewohnlicher 
arithmetischer Befehle verringert wird. Zur Einhaltung 
der Systeminvariante wird zur Ablage eines Zeigers auf 
dem Zeigerstapel ein spezieller Befehl bereitgestellt , 

20 der in nicht unterbrechbarer Weise zuerst den Zeiger an 
der ersten unbelegten Speicherstelle des Zeigerstapel - 
bereiches ablegt und den Zeigerstapel index erhoht. Dies 
ist gleichzeitig der einzige Befehl, mit dem der 
Zeigerstapel index erhoht werden kann. 

25 

Bei der bisher beschriebenen Prozessorarchitektur 
kann ausschlieSlich uber Zeiger auf den Speicher zuge- 
griffen werden, und die einzige Moglichkeit zur Erzeu- 
gung von Zeigern besteht im Anlegen neuer Objekte mit 
30 Hilfe des Objekterzeugungsbef ehls . Es sollte jedoch 

auch moglich sein, auf konstante Daten zuzugreifen, die 
bspw. als Teil des Programmcodes bereits vor dem Start 
des Programmes existieren. Beispiele fur solche kon- 
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stanten Daten sind konstante Zeichenketten oder vom 
Compiler generierte Strukturen wie bspw. Verzweigungs- 
tabellen oder Typbeschreibungen . 

Das vorliegenden Beispiel einer vorteilhaf ten 
5 Ausgestaltung der Prozessorarchitektur fiihrt daher 
konstante Objekte ein. Ein konstantes Objekt ist 
hierbei ein unveranderbares Objekt, das als Teil des 
Programmcodes oder in einem speziellen Bereich abge- 
speichert wird, der fur konstante Objekte reserviert 

10 ist. Fur die Erzeugung von Zeigern auf konstante 

Objekte, nachfolgend als konstante Zeiger bezeichnet, 
wird ein spezieller „Erzeuge konstanten Zeiger" -Befehl 
verwendet . Speicherzugrif f e uber konstante Zeiger sind 
auf Lesezugriffe beschrankt, und der Zeigerbereich 

15 eines konstanten Objekts darf ausschlieSlich konstante 
Zeiger oder Null -Zeiger enthalten. Konstante Objekte 
werden von gewohnlichen Objekt en durch ein q>-Attribut 
unterschieden, das zur Unterscheidung spezieller Arten 
von Objekten bereitgestellt wird. 

20 

In vielen Systemen werden getrennte Programmstapel 
fur unterschiedliche Betriebsarten wie bspw. Anwender- 
modus und Betriebssystemmodus verwendet . Daruber hinaus 
erfordern Systeme mit mehreren nebenlauf igen Ausfuh- 

25 rungs faden (mult i -threaded systems) separate Programm- 
stapel fur jeden Ausf iihrungsf aden. Alle diese Stapel 
werden ublicherweise vom Betriebssystem verwaltet und 
befinden sich nicht in dem von der automatischen Spei- 
cherbereinigung uberwachten Speicherbereich (Heap) . 

30 Urn es dem Betriebssystem zu ermoglichen, Speicher- 

bereiche auSerhalb des Heap-Speicherbereiches zu ver- 
walten, werden statische Objekte bereitgestellt. Stati- 
sche Objekte werden ausschlieSlich im Betriebssystem- 
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modus erzeugt und in einem speziell dafiir vorgesehenen 
Speicherbereich angeordnet . Statische Objekte werden 
ebenfalls uber das <p-Attribut identif iziert . Zeiger auf 
statische Objekte (statische Zeiger) sind fur Anwender- 
5 programme niemals sichtbar. 

Zur Einhaltung der Systeminvariante muss jeder 
Zeiger in einem neu erzeugten Objekt mit dem Null -Wert 
initialisiert werden, bevor der zugehorige Objekterzeu- 
gungsbefehl abgeschlossen werden kann. Deshalb ist die 
Ausfuhrungszeit fur den Objekterzeugungsbef ehl nicht 
durch eine kleine Zeitkonstante begrenzt . Dies ist fur 
harte Echtzeitanwendungen nicht akzeptabel . 

Urn den Obj ekterzeugungsbef ehl unterbrechbar zu 
gestalten, werden in der beschriebenen vorteilhaf ten 
Ausgestaltung der Prozessorarchitektur uninitialisierte 
(genauer: unvollstandig initialisierte) Objekte einge- 
fiihrt. Uninitialisierte Objekte werden dann und nur 
dann erzeugt, wenn der Zuweisungsbef ehl vor der Fertig- 
stellung eines Objekts unterbrochen wird. Zeiger auf 
uninitialisierte Objekte sind nur im Betriebssystem- 
modus sichtbar und durfen niemals deref erenziert 
werden. Uninitialisierte Objekte werden - wie statische 
und konstante Objekte - durch das (p-Attribut identif i- 
ziert • 

Die beispielhaft beschriebene vorteilhafte Ausge- 
staltung der Prozessorarchitektur unterstutzt folglich 
vier unterschiedliche Art en von Objekten: normale dyna- 
3 0 mische Objekte, uninitialisierte dynamische Objekte, 

konstante Objekte und statische Objekte. Das <p-Attribut 
wird zur Unterscheidung der Objektarten eingesetzt und 
kann einen der vier Werte (norm, uini, const, stat) an- 
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nehmen. In einer Implement ierung der Architektur kann 
das (p-Attribut im Zeiger auf ein ObjeJct und/oder im 
Objekt selbst abgelegt werden. 

Normale dynamische Objekte und uninitialisierte 
5 dynamische Objekte befinden sich im Heap- Speicherbe- 
reich, statische Objekte im statischen Speicherbereich 
und konstante Objekte in dem fur den Programmcode 
und/oder konstante Daten vorgesehenen Speicherbereich . 
Da statische und uninitialisierte Objekte auf den 

10 Betriebssystemmodus beschrankt sind, werden sie als 
Systemobjekte bezeichnet. 

Unter dem Gesichtspunkt der automatischen 
Speicherbereinigung konnen die vier Objektarten dadurch 
charakterisiert werden, wie sie von einem kompaktieren- 

15 den Speicherbereiniger behandelt werden. Gewohnliche 
dynamische Objekte mussen nach Zeigern durchsucht und 
bei einer Kompaktierung verschoben werden. Statische 
Objekte mussen zwar nach Zeigern durchsucht, durfen 
aber nicht verschoben werden. Uninitialisierte Objekte 

20 dagegen mussen wahrend der Kompaktierung verschoben 
werden, durfen aber nicht nach Zeigern durchsucht 
werden, da sie ungultige Zeiger enthalten konnen. 
SchlieSlich mussen konstante Objekte vom Speicherberei- 
niger weder nach Zeigern durchsucht noch verschoben 

25 werden. 

Eine mogliche Implement ierung der vorgeschlagenen 
Prozessorarchitektur wird im Folgenden beispielhaft 
erlautert. Fur die Implement ierung wird eine WortgroSe 
30 von 32 Bit angenommen. Der Speicher ist byteweise 
adressierbar , urn innerhalb des Datenbereiches auch 
Byte- und Halbwortzugrif f e zu ermoglichen. Worte mussen 
an durch vier teilbaren Adressen ausgerichtet werden. 
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Ein beispielhaf tes Layout eines Objekts im 
Speicher ist in der Figur 5 dargestellt . Jedes Objekt 
besteht aus einem Datenbereich, einem Zeigerbereich und 
einem Attributbereich. Aus Ef f izienzgrunden sind die 
5 Objekte an durch acht teilbaren Adressen ausgerichtet , 
wodurch unter Umstanden ein Full-Bereich zwischen zwei 
Objekten erforderlich werden kann. Der Attributbereich, 
der fur Nutzerprogramme unsichtbar ist, beinhaltet die 
71 und 8-Attribute des Objekts. Aufgrund der Unter- 
10 stiitzung von Byte- und Halbwortoperanden andert die 

vorliegende Implement ierung die .Definition von n und 5 
leicht, da sie nun die Anzahl von Bytes anstelle der 
Anzahl der Worte in dem entsprechenden Bereich be- 
schreiben . 

15 Da n ein Vielf aches von vier sein muss, bleiben im 

Speicherwort , das fur das 7i-Attribut verwendet wird, 
zwei Bits unbelegt. Diese konnen zur Ablage des <p- 
Attributs (oder Teilen davon) und/oder von einem 
Speicherbereiniger verwendet werden. 

20 

Die Zeiger enthalten direkt die physikalische 
Speicheradresse des Objekts. Da die Objekte nach 
Doppelworten ausgerichtet sind, belegt die Objekt - 
adresse lediglich 2 9 Bits eines Zeigerwortes . Die 
2 5 verbleibenden drei Bits konnen zur Ablage des cp- 
Attributs (oder Teilen davon) und/oder von einem 
Speicherbereiniger verwendet werden. 

Vor dem Zugriff auf ein Objekt mussen die Attri- 
30 bute des Objekts bekannt sein, da diese fur die 

Bereichsuberpriif ung vor dem Zugriff benotigt werden, 
und, im Falle eines Objekt layouts gemaS Figur 5, im 
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Falle eines Datenzugrif f s zusatzlich fur die Adresser- 
zeugung er f order lich sind. 

Da das Laden der Attribute aus dem Speicher vor 
jedem Objektzugrif f mit einem groSen Overhead verbunden 
ist, wird jedem Zeigerregister ein Attributregister 
beigestellt, wie dies in der Figur 6 schematisch darge- 
stellt ist. Wenn ein Zeigerregister einen Wert enthalt, 
der nicht Null ist, beinhaltet das korrespondierende 
Attributregister die Attribute des Objekts, auf das das 
Zeigerregister verweist. Auf diese Weise wird der 
Aufwand fur die Deref erenzierung eines Zeigerregisters 
so gering wie der Aufwand fur die Adresserzeugung in 
konventionellen Architekturen. Die Bereichsuberpruf ung 
selbst ist mit keinen LeistungseinbuSen verbunden, da 
sie parallel zur Adressberechnung durchgefiihrt werden 
kann . 

Die Attributregister haben jedoch ihren Preis: 
Wenn ein Zeiger aus dem Speicher geladen wird, mussen 

2 0 auch die zugehorigen Attribute in die Attributregister 

geladen werden. Hinzu kommt, dass der Ort der Attribute 
im Speicher erst bekannt ist, wenn das Laden des 
Zeigers abgeschlossen ist. 

Dieses Problem kann im Falle einer RISC-Architek- 
25 tur effizient durch eine zusatzliche Pipelinestuf e nach 
der ublichen Speicherstuf e gelost werden. Diese zusatz- 
liche Stufe wird als Attributstuf e bezeichnet und ver- 
wendet einen At tribut -Cache, um Attributzugrif f e in den 
meisten Fallen ohne LeistungseinbuBen auszufuhren. Der 

3 0 Aufbau des Attribut -Cache ist dem eines gewohnlichen 

Daten-Caches ahnlich. Der Attribut -Cache wird durch die 
oberen 2 9 Bits eines Zeigers adressiert und ermoglicht 
das Lesen oder Schreiben der n und 5-Attribute in einem 
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einzigen Schritt. Der wesentliche Unterschied zu einem 
Daten-Cache besteht in der GroSe der Cache- Zeilen. 
Wahrend Cache-Zeilen in Daten-Caches ublicherweise 8 
Worte umfassen, weist eine Zeile des Attribut -Cache 
5 eine Breite von 2 Worten auf und enthalt lediglich die 
Attribute eines einzelnen Objekts. 

Figur 7 zeigt die Grundstruktur der implemen- 
tierten Pipeline und Figur 8 die Zerlegung aller 
10 zeigerbezogenen Befehle auf die einzelnen Pipeline- 

Stufen. Zur Veranschaulichung wird die Abarbeitung der 
beiden auf wandigsten Befehle beispielhaft beschrieben. 

1. „Lade Zeiger "-Bef ehl : 

In der Ausf uhrungsstuf e der Pipeline berechnet die 
Adresserzeugungseinheit (AGU: Address Generation Unit) 
die Speicheradresse des zu ladenden Zeigers und fuhrt 
parallel dazu die von der Architektur vorgeschriebenen 
Lauf zeittests wie bspw. Bereichsuberpruf ungen und Null- 
zeigertests durch. In der Speicherstuf e wird die be- 
rechnete Adresse benutzt, urn den Zeiger aus dem Objekt- 
Cache zu lesen. Der geladene Zeiger adressiert dann den 
Attribut -Cache, um die Attribute aus dem Objekt zu 
laden, auf das der geladene Zeiger zeigt. SchlieSlich 
wird der geladene Zeiger zusammen mit den geladenen 
Attributen in den Registersatz geschrieben. 

2 . Ob j ekter zeugungsbef ehl : 

Die Grofie des zu erzeugenden Objekts wird mit Hilfe 
3 0 zweier Datenoperanden bestimmt, die aus der Dekodier- 

stufe in die Ausf uhrungsstuf e weitergereicht werden. In 
der Ausfuhrungsstuf e ist die Zeigererzeugungseinheit 
(PGU: Pointer Generation Unit) fur die Erzeugung des 
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Zeigers auf das neue Objekt zustandig. Im Falle eines 
kompaktierenden Speicherbereinigers kann die PGU die 
Startadresse des neuen Objekt s sehr einfach dadurch 
bestimmen, dass die Objektgrofie zum Inhalt eines 
5 Systemregisters addiert wird, das stets auf das letzte 
belegte Wort in dem Bereich des Heaps zeigt, der fur 
das Anlegen neuer Objekte verwendet wird. Die PGU wird 
durch die AGU unterstutzt, die die fur die Zeigerini- 
tialisierung erf orderlichen Adressen erzeugt . Bei einem 

10 Objekt -Cache mit Cache- Zeilen von 8 Worten konnen in 
einem Taktzyklus bis zu 8 Zeigerworte gleichzeitig 
initialisiert werden. Auf diese Weise durchlauft der 
Erzeugungsbef ehl die Ausfuhrungsstuf e ohne Verzogerung, 
wenn die Startadresse des Objekt s innerhalb eines Takt- 

15 zyklus berechnet werden kann und wenn alle Zeiger im 
Objekt der gleichen Cache-Zeile angehoren. Falls dies 
nicht der Fall ist, wird die Pipeline angehalten, bis 
die Initialisierung abgeschlossen ist oder eine Unter- 
brechung auftritt. SchlieSlich werden die Attribute des 

2 0 neu generierten Objekts in den Attribut -Cache und der 
Zeiger zusammen mit seinen Attributen in den Register- 
satz geschrieben. Falls ein unterbrochener Objekterzeu- 
gungsbefehl am Ende der Pipeline ankommt, wird der Zu- 
stand der unterbrochenen Objekterzeugung in ein System- 

2 5 register geschrieben und das unvollstandig initiali- 
sierte Objekt mit dem <p-Attribut fur uninitialisierte 
Objekte gekennzeichnet . Die Initialisierung wird wieder 
aufgenommen, sobald der Ausf uhrungskontext (Befehls- 
folgezahler, Systemregister) des unterbrochenen Pro- 

30 gramms wieder hergestellt ist. 

Die Funktionsf ahigkeit der vorgeschlagenen Archi- 
tektur wurde anhand eines f unktionierenden Prototypen 
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reiniger als mikroprogrammierter Koprozessor reali- 
siert, der eng mit der Pipeline des Hauptprozessors 
zusammenarbeitet . Die Synchronisation zwischen Pro- 
5 zessor und Koprozessor ist komplett in Hardware reali- 
siert. Der Prozessor und der Koprozessor fur die 
Speicherbereinigung sind in VHDL beschrieben und 
gemeinsam fur einem modernen programmierbareren 
Logikbausteins synthetisiert . Es existieren weiterhin 
10 ein prototypischer Java -Compiler sowie die Implement ie- 
rung einer Untermenge der Java-Klassenbibliotheken fur 
die Architektur. 

Figur 9 zeigt eine schematische Darstellung eines 

15 Beispiels der vorliegenden Vorrichtung. Der Speicher- 
bereiniger wird in diesem Beispiel durch einen 
mikroprogrammierbaren Coprozessor 2 gebildet. In den 
Hauptprozessor 1 ist die erf indungsgemafie Prozessor- 
architektur implement iert . Ein Speicher-Controller 3 

2 0 mit jeweils mehreren getrennten Ports fur den Haupt- 
prozessor 1 und den Coprozessor 2 stellt die Verbindung 
zum Hauptspeicher her. Die Synchronisation zwischen 
Haupt-und Coprozessor findet auf unterschiedlichen 
Ebenen statt. Der Speicherbereiniger verriegelt oder 

25 raumt Zeilen des Daten- und Attribut -Caches , wenn 

notig, urn die Cache -Koharenz zu gewahrleisten. Eine in 
die Prozessor-Pipeline integrierte Hardware -Lese- 
barriere kann Interrupts im Speicherbereiniger 
triggern. Der Speicherbereiniger kann den Haupt- 

30 prozessor 1 auch stoppen, urn kritische Bereiche im 
Mikrocode zu schutzen. 
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Patentanspruche 



10 



15 



Prozessorarchitektur, bei der der Zugriff auf 
einen Speicher uber Zeiger erfolgt, die auf 
Objekte verweisen # dadurch gekennzeichnet , 
dass in den Objekten Zeiger in einem Zeigerbereich 
und Daten in einem Datenbereich getrennt voneinan- 
der abgelegt werden, wobei die Zeiger eine Spei- 
cheradresse des Objekts enthalten, auf das sie 
verweisen und die Objekte mit Attributen versehen 
werden, die im Objekt selbst abgelegt werden und 
die eine Lange des Zeigerbereiches und eine Lange 
des Datenbereiches beschreiben, und 
dass der Prozessor einen Registersatz mit ge- 
trennten Daten- und Zeigerregistern bereitstellt , 
von denen die Zeigerregister fur den Zugriff auf 
Objekte im Speicher verwendet werden. 



20 



Prozessorarchitektur nach Anspruch 1, 
dadurch gekennzeichnet, 

dass der Prozessor gewahrleistet , dass jeder 
Zeiger nur entweder einen vorgegebenen Null -Wert 
oder die Speicheradresse eines existierenden 
Ob j ekt s enthal t . 



25 



Prozessorarchitektur nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, 

dass ein Befehlssatz mit getrennten Befehlen fur 
Daten- und Zeigeroperationen eingesetzt wird. 
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4 . Prozessorarchitektur nach einem der Anspruche 1 
bis 3, 

dadurch gekennzeichnet , 

dass Lade- und Speicheroperationen fur Zeiger 
5 ausschlieSlich Zeiger aus den Zeigerbereichen der 

Objekte in Zeigerregister laden bzw. den Inhalt 
von Zeigerregistern in den Zeigerbereichen der 
Objekte speichern, und 

dass Lade- und Speicheroperationen fur Daten 
10 ausschlielSlich Daten aus den Datenbereichen der 

Objekte in Datenregister laden bzw. den Inhalt von 
Datenregistern in den Datenbereichen der Objekte 
speichern. 

15 5. Prozessorarchitektur nach einem der Anspruche 1 
bis 4, 

dadurch gekennzeichnet , 

dass ein Befehlssatz mit einem Objekterzeugungs- 
befehl verwendet wird, der alle Zeiger im Zeiger- 
2 0 bereich eines erzeugten Objekts mit einem Null- 

Wert initial isiert, bevor auf das erzeugte Objekt 
zugegriffen werden kann. 

6, Prozessorarchitektur nach Anspruch 5, 
25 dadurch gekennzeichnet, 

dass der Objekterzeugungsbef ehl unterbrochen und 
zu einem spateren Zeitpunkt fortgesetzt werden 
kann. 



3 0 7. Prozessorarchitektur nach Anspruch 6, 
dadurch gekennzeichnet, 

dass beim Unterbrechen des Obj ekterzeugungsbef ehls 
unvollstandig initialisierte Objekte erzeugt 
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werden, die vom Prozessor eindeutig von 
vollstandig initialisierten Objekten unterschieden 
werden. 

5 8. Prozessorarchitektur nach einem der Anspruche 1 
bis 7 , 

dadurch gekennzeichnet , 

dass der Prozessor konstante Objekte unterstutzt, 
die in einem separaten Speicherbereich gehalten 
10 werden, der zur Programmlauf zeit ausschlieSlich 

gelesen wird, und 

dass Zeiger auf konstante Objekte vom Prozessor in 
eindeutiger Weise gekennzeichnet werden. 

15 9. Prozessorarchitektur nach einem der Anspruche 1 
bis 8 , 

dadurch gekennzeichnet, 

dass ein Programmstapel verwendet wird, der in 
einen Zeigerstapelbereich und in einen Datensta- 
20 pelbereich unterteilt ist, wobei eine Lange des 

belegten Teils in jedem der beiden Stapelbereiche 
durch je einen Stapelindex angezeigt wird, der in 
je einem dafur reservierten Datenregister verwal- 
tet wird. 

25 

10. Prozessorarchitektur nach Anspruch 9, 
dadurch gekennzeichnet, 

dass zur Ablage eines Zeigers auf dem Zeigerstapel 
ein Befehl verwendet wird, der in nicht unter- 
3 0 brechbarer Weise sowohl den entsprechenden Zeiger 

auf dem Zeigerstapel ablegt als auch den Zeiger- 
stapel index erhoht . 
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Prozessorarchitektur nach einem der Anspruche 1 
bis 10, 

dadurch gekennzeichnet , 

dass der Prozessor statische Objekte unterstiitzt, 
die in einem separaten, von einem Betriebssystem 
verwalteten Speicherbereich gehalten werden, und 
dass Zeiger auf statische Objekte vom Prozessor in 
eindeutiger Weise gekennzeichnet werden. 

Prozessorarchitektur nach Anspruch 9 in Verbindung 
mit Anspruch 11 oder Anspruch 10 in Verbindung mit 
Anspruch 11, 

dadurch gekennzeichnet, dass 

fur den Programmstapel statische Objekte verwendet 
werden, wobei die im Objekt enthaltenen Attribute 
bei einem nicht aktiven Programmstapel jeweils die 
Lange eines tatsachlich belegten Teils des Stapel- 
bereichs beschreiben . 

20 13. Prozessorarchitektur nach einem der Anspruche 1 
bis 12, 

dadurch gekennzeichnet, 

dass jedem Zeigerregister ein Attributregister 
zugeordnet wird, in das die Attribute des Objekts 

2 5 geschrieben werden, auf das der Zeiger im Zeiger- 

register verweist. 

14. Prozessorarchitektur nach Anspruch 13, 
dadurch gekennzeichnet, 

3 0 dass eine Pipeline mit einer zusatzlichen 

Pipeline-Stuf e zum Laden der Attribute eingesetzt 
wird. 



11. 



5 



10 12. 



15 
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15. Prozessorarchitektur nach Anspruch 13 oder 14 , 
dadurch gekennzeichnet , 

dass ein Attribut -Cache eingesetzt wird. 

5 16. Prozessorarchitektur nach einem der Anspriiche 1 
bis 15, 

dadurch gekennzeichnet, 

dass ein RISC-Bef ehlssatz verwendet wird. 



10 17. Prozessorarchitektur nach einem der Anspriiche 1 
bis 16, 

dadurch gekennzeichnet, 

dass der Prozessor eine automatische Speicher- 
bereinigung durchf iihrt . 

15 

18. Prozessor, in den die Prozessorarchitektur nach 
einem der vorangehenden Anspriiche implement iert 
ist . 



20 19. Vorrichtung mit einem Hauptprozessor (1), in den 
die Prozessorarchitektur nach einem der Anspriiche 
1 bis 16 implementiert ist, und einem Coprozessor 
(2) , der zur Durchf iihrung einer automatischen 
Speicherbereinignung ausgebildet und fur eine 

25 effiziente Synchronisierung eng mit dem Haupt- 

prozessor (1) gekoppelt ist. 



20 . 



Verwendung der Prozessorarchitektur nach einem der 
Anspriiche 1 bis 17 fiir eingebettete Systeme. 
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Befehle, die Zeigerregister lesen 

Speichere Zeiger (store pointer) sp py[index] := pz 

Kopiere Zeiger (copy pointer) cpp px := pz 

Vergleiche Zeiger (compare pointers) cmpp dx := py.pz 



Befehle, die Zeigerregister schreiben 








Erzeuge Objekt (allocate object) 


ale 


px 


:= dy.dz 


Lade Zeiger (load pointer) 


IP 


PX 


:= py[index] 


Kopiere Zeiger (copy pointer) 


cpp 


PX 


:= pz 


Erzeuge konst. Zeiger (create const, pointer) 


ccp 


PX 


:= dy 



Befehle, die Zeigerregister dereferenzieren 






Lade Datum 


(load data) 


Id 


dx := py[index] 


Lade Zeiger 


(load pointer) 


IP 


px := py[index] 


Speichere Datum 


(store data) 


sd 


py[index] := dz 


Speichere Zeiger 


(store pointer) 


sp 


pypndexj := pz 


Lese 71-Attribut 


(read 7t-attribute) 


pattr 


dx := py 


Lese 5- Attribut 


(read 8- attribute) 


dattr 


dx := py 



dx, dy, dz Datenregister 
px, py, pz Zeigerregister 
index Ausdruck fur Indizierungsart 



WO 2005/003960 ^ § _ PCT/EP2004/007175 

4/ t 



I 



(Fullbereich) 



Datenbereich 



Zeigerbereich 



Attributbereich 



px[8-4] □ 



px + 8 + 7c + 5- 4 



I 



K A L°J 1 — 1 


px + 8 + n + 8 

nv 4. ft x tt x A 

px + 8 + n + 0 


n*r4i n 

PX|HJ LJ 


px[01 □ 


px[rc-4] ,X 


px + 8 + 7i - 4 

px + 8 + 8 
px + 8 + 4 
px + 8 + 0 




px[8] / 


px[4] 


px[0] 


6 


px + 4 
px 


71 


1 


Adresse 



Fia. 5 



i 1 r 

! <px : : 

1 I u 



71X 



1 r ■ 

i i 

i i 

i i_ . 



6x j 



Fig. 6 



WO 2005/003960 5/7 PCT/EP2004/007175 



aqoeojnquuv 



O 



□ 

1 

TTT 
□ v «r 



? \> 1 



eqoBopiafqo 



ill 



TTT 



TT 



3 
Q_ 



rn 



I I 1 1 I I i 1 



D X jf □ \> 



UJ 

- 

b 

9 
E 

< 



UJ 
X 

g 
2 
a. 

CO 



z 

UJ 



11. 

CO 

< 



5» 

I 
1 

[nil 



«2. 

I 

I 



I I I 



TTT 

% to 



japo^aa 



aqoBOSjiiajag 



UJ 

tc 

UJ 
Q 

UJ 
Q 



UJ 

-J 
O 



t: 

i 



1 



u m 



Fig. 7 



WO 2005/003960 



6/7 



PCTYEP2004/007175 



UJ 

- 
m 

E 
< 



□IS 



HI 

c 
■> 

UJ 
£L 

CO 



z 

UJ 



CD 
3 



UJ 

oc 

UJ 
Q 

§ 

UJ 
Q 



I I 



« £ rs Iml Is 



col I col 



III Ml 



ir>| 



< < 



PI 

I CD I 



Pi 
cgl 



< < 



x 

3 



«o 1 


Icq 1 


to 






s 




{□] 


p 


)eranden 


jeranden 


)eranden 




pi 


P 


lese 


lese 


lese 



1 c \ 

\m 

I CD I 



C 

CD 
Q 



Ol O 



© 

col 

CD 



□1 !□ 



i i 



O IB 



i i 



□I ID 



3| p 
— f I -j 

< < 



CD ] CD 
T> IX 
C I C 

S U5 

CD CD 
Qj I O. 

CD 1 I CD 
COl I CO 
CD I | CD 



N 



~ I 

a 

CD I 
D 

Ol 

"5 



J 3 
1-91 

N 

1 <d| 

si rs 



CD] 



CO] 

"col 



3 

O 
Q_ 

CD 



P 

M . 
|Q-| Icl 



Dl □ 



CD 

s 



CD 

ml 
1 c\ 

S 

CD 



P^ P 



CD 

col 

CD I 



CD I 

col 

<D| 



WO 2005/003960 PCT/EP2004/007175 

7/7 





1 
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